Comparison Of Measured Network Stability And Packet Loss Rates Between Korean Servers And Hong Kong Servers At Different Time Periods

this article draws conclusions based on active measurements of networks in multiple places at different time periods: generally speaking, hong kong servers located around china have an advantage in latency and network stability during peak periods, while korean servers perform similarly during off-peak periods but packet loss increases more significantly at night or when cross-border links are congested. the following explains the time periods, indicators and optimization suggestions, and provides actual measurement methods and practical judgment basis.

which time period has the largest difference in delay and packet loss?

we divide the day into: early morning (02:00–06:00), working period (09:00–17:00), and evening peak (19:00–23:00). actual measurement results show that the biggest difference between the two is during the evening peak period: the average round-trip delay (rtt) of hong kong servers is usually 20–40ms, and the packet loss rate is mostly between 0–0.8%; while the average rtt of korean servers is 45–85ms, and the packet loss rate may rise to 1.5–3% during the evening peak (individual nodes burst to 5%). both delays and packet losses dropped significantly during the early morning period, and the stability was close, indicating that cross-border link congestion was the main cause.

where can i visually see network jitter and packet loss distribution?

problem nodes can be intuitively located through continuous ping, traceroute and iperf3 parallel sampling. in actual measurements, packet loss is mostly concentrated at certain asns or transit nodes on international exits and backbone links (traceroute shows hop timeout or sudden increase in delay). in multiple samples, the path to the korean server is more likely to experience intermittent packet loss at the international submarine/terrestrial cable arrival link or the domestic exit in south korea; while the path to the hong kong server is more critical at the local access and intercity backhaul link. if the local operator's backhaul is congested, the hong kong node will also experience short-term packet loss.

why do periodic fluctuations and regional differences occur?

periodic fluctuations mainly come from bandwidth occupation and link sharing: the increase in user traffic during evening peaks and the concentration of high-traffic services such as p2p/video, leading to queuing and packet loss at international exports or certain links. regional differences are related to geographical distance, routing selection, and operator interconnection relationships (peering). for example, the route to the hong kong server is usually shorter and the peering between operators is mature; while the route to the korean server may go through an additional transit asn or backhaul path, and bottlenecks in any link will amplify packet loss and jitter.

how many samples and what tools can ensure the credibility of the test conclusion?

to draw robust conclusions, it is recommended to collect at least 72 hours of continuous data for each time period, with sampling intervals of 1 minute or less. commonly used tools include: ping (packet loss rate and rtt distribution), mtr/traceroute (routing and hop count delay), iperf3 (bandwidth and packet loss performance under high load), tcpdump (packet capture analysis and retransmission). using the cumulative distribution function (cdf) and box plots of the results of different time periods and different destination ips can more intuitively determine the median and outliers.

how to analyze and interpret measured data to make site selection decisions?

first, look at the packet loss rate and median delay: for interactive services (games, real-time voice), give priority to solutions with low latency and stable packet loss at <0.5%; for static content, higher delays can be tolerated, but attention should be paid to retransmissions caused by peak packet loss. secondly, observe jitter and sudden packet loss: if packet loss increases intermittently during a certain period, link queuing or operator policies should be suspected. finally, it is decided to choose a hong kong server or a korean server based on factors such as business user distribution, cost and compliance.

how to optimize or alleviate cross-time packet loss and instability issues?

common optimization measures include: multi-point deployment and intelligent scheduling (switching traffic to the nearest node based on delay/packet loss), selecting computer rooms or service providers with excellent interconnection relationships, using protocols such as tcp optimization or quic to reduce retransmission overhead, and adding fec/retransmission strategies to the transport layer. in actual measurements, offloading traffic to hong kong nodes can reduce user-perceived latency and packet loss to a lower level during the evening peak. for services close to korean users, it is recommended to deploy and distribute traffic in both korea and hong kong at the same time.

which metric is more critical, latency or packet loss rate?

both are critical but depend on the type of business: for real-time interactive services (voice, video conferencing, games) packet loss rate and jitter are usually more damaging than a single delay, because packet loss will trigger retransmission or quality degradation; for downloads or api requests, if the packet loss is low but the delay is high, users can still accept it but the response time becomes longer. the comprehensive indicator can be measured by "effective throughput + experience loss". it is more convincing to report the median rtt, 95th percentile, packet loss rate and jitter at the same time during actual measurement.

where can i quickly reproduce the method in this article and collect data?

scripts (based on ping, mtr, iperf3) can be started locally or in the cloud to regularly sample using cron and report to tsdb (such as influxdb) or csv, in conjunction with grafana visualization. it is recommended to sample the exits of at least three different operators at the same time, and conduct various port and protocol tests (icmp/tcp/udp) on each target server to prevent misjudgment caused by a single protocol being rate limited or filtered.